知らなかったのは私だけでしょうか･･･。東京リージョンでも Amazon Athena フェデレーテッド・クエリが GA されていました

え・・・いつからそこに居たの。

ずっと待ってたんだよ・・・

ということで、ひっそりと東京リージョンでも Amazon Athena の Federated Query が GA されていました。

いつから？

2020年12月16日にドキュメント更新されていたようです。

こんな待望のアップデートを 1 ヶ月も見落としていたなんて。。私、アップデート職人だと自負していましたが、これはアップデート職人引退が迫られる事案だと重く受け止めています。。

Amazon Athena Federated Query

Amazon Athena のフェデレーテッド・クエリはリレーショナル、非リレーショナル、オブジェクト、およびカスタムのデータソースに格納されているデータに対して SQL クエリを実行できるようになる機能です。フェデレーテッド・クエリについては以下のブログを参照ください。

これまで Athena のエンジンバージョン 1 でプレビュー版として提供されていましたが、昨年の 11 月にエンジンバージョン 2 として GA されました。

が、エンジンバージョン 2 の GA に東京リージョンは含まれておらず、ガッカリしたのを覚えています。

「東京リージョンで早く使いたいなぁ」

と、ずっと待ち焦がれていたのに、まさかひっそりと GA されていたとは。

なにはともあれ、東京リージョンで早速つかってみましょう！

やってみる

エンジンバージョン2のワークグループ作成

フェデレーテッド・クエリを利用するには Athena のエンジンバージョン 2 を利用する必要があります。エンジンバージョンはワークグループ単位で設定が可能です。

既存のワークグループを変更することも可能ですが、エンジンバージョンの違いによって細かな点で違いがあるので既存資産に影響なく利用したいのであればワークグループを新規に作成するのが良いでしょう。

エンジンバージョンのアップデート内容については、以下の記事を参照ください。

Athena のダッシュボードを開き [Workgroup] を開きます。[Create workgroup] をクリックします。任意のワークグループ名を入力、Query engine version > Manually choose an engine version now > Athena engine version 2 (recommended) を選択し [Create workgroup] をクリックします。

以下のようにワークグループが作成されますので、作成したばかりのワークグループを選択し、[Switch workgroup] をクリックします。

データソースコネクタのデプロイ

フェデレーテッド・クエリを利用するには各サービスに接続するためのコネクタが必要になります。Athena のフェデレーテッド・クエリでは、このコネクタ部分に Lambda 関数を利用しています。

（引用元：Amazon Athenaの新しいフェデレーテッド・クエリによる複数データソースの検索）

Athena のダッシュボードから [Data Sources] を開き、[Connect data source] をクリックします。[Connect data source] ページで Query a data source を選択すると、選択可能なデータソースが表示されます。

今回は Amazon CloudWatch Logs を選択しています。

コネクタとなる Lambda 関数を選択しますが、今回は新規のため Configure new AWS Lambda function を選択します。

Lambda 関数の作成画面が表示されます。[アプリケーションの設定] で SpillBucket と AthenaCatalogName を入力します。

SplitBucket は Lambda 関数のレスポンスサイズを超えるデータを保存するための S3 バケットになります。ちなみに S3 バケットは作成されませんので、事前に作成しておきましょう。

AthenaCatalogName は Lambda 関数名になりますのでターゲットデータソースがわかるような名前にすると良いでしょう。

このアプリがカスタム IAM ロールを作成することを承認します。 にチェックを入れてデプロイします。

[デプロイ] タブを開き、デプロイメント状況が Create complete になっていればデプロイ完了です。

データソースへの接続

Athena の画面に戻り、作成したばかりの Lambda 関数を指定します。Catalog name は SQL ステートメント内でこのデータソースを指定するために利用します。今回は cloudwatchlogs としました。最後に [Connect] をクリックします。

これで Athena から CloudWatch Logs への接続は完了です。

CloudWatch Logs にクエリを投げてみる

それではクエリエディタから簡単なクエリを投げてみましょう。FROM 句の指定方法は以下のとおりです。

MyCloudwatchCatalog.database_name.table_name

今回はカタログ名に cloudwatchlogs としています。CloudWatch Logs の場合、データベース名はロググループ名、テーブル名がログストリーム名です。

例えばロググループ flowlogs 内の全ログストリームを対象にしたい場合は all_log_streams を指定し、以下のようなクエリになります。

SELECT * FROM "cloudwatchlogs"."flowlogs"."all_log_streams" limit 10;

Athena から CloudWatch Logs にクエリが投げれることが確認できましたね！最高やん。

You do NOT own the spill bucket with the name

クエリを実行した際に You do NOT own the spill bucket with the name というようなメッセージでエラーになる場合、SplitBucket で指定した S3 バケットが存在していないと思われますので、きちんと作成しましょう。

自動作成してくれたらありがたいんですけどね。。

データソースを削除するとき

Athena のデータソースを削除しても Lambda 関数は削除されません。裏では AWS サーバーレスアプリケーションでデプロイされてるので CloudFormation からアプリケーションのスタックを削除する必要があります。

さいごに

Athena のフェデレーテッド・クエリがついに東京リージョンでも GA されましたね！（というか、されていましたね！）

CloudWatch Logs Insights だと高度なクエリができなくてフェデレーテッド・クエリを早く使いたい！というお声をお客さまからいただくことが多かったので、本当に待望のアップデートだと思います！

フェデレーテッド・クエリを使った便利なユースケースが思いついたら、どんどん情報発信していきましょう！

以上！大阪オフィスの丸毛（@marumo1981）でした！

参考

• 公式ドキュメント
  • Deploying a Connector and Connecting to a Data Source
  • Writing Federated Queries